A number of third-party vendors market software which provides authentication and authorization services. One example is a service that protects web-based resources. When a user enters a valid login ID and password, the authentication and authorization service retrieves the user's data from a database and displays a personalized HTML page. These authentication software packages (also referred to herein as “authenticators”) store and organize the authentication information in various datastores (databases, directory services, etc). In keeping with the secure nature of the information many of the vendors use proprietary schemes and/or encryption to store such information. While this provides added security to that vendor's system, it also makes it more difficult to increase and/or customize modifications to desired levels of security within a large database.
By storing all of an enterprise's security-only related information (the information that may be required for an authentication and authorization) in one place, and not cluttering the datastore up with other information that is not security related, the resultant database can be made smaller and easier to maintain. Such design creates a more secure site by preventing users from retrieving information for day to day events that do not require protection, thus reducing traffic to the protected site and increasing efficiency. However, there may be other information stored separately within an enterprise that is not security related information, but still requires protecting, for example privacy related information. Having multiple sites that require protection creates redundancies within the security architecture of an enterprise resulting in economic inefficiencies. Therefore, there exists a need in the art for integrating security and privacy information for the purposes of streamlining protection efforts within enterprise architecture.